r? @kennytm

(rust-highfive has picked a reviewer for you, use r? to override)

but isn't proc_macro specializing ToString an example why the default fn should be kept public 🤔

proc_macro will still use the specialized version, just not publicly

actually #32586 (comment) questioned the rationale of making ToString publicly specializable, the response was

Very good question. We talked about this some in a recent libs meeting -- ultimately, we're going to want a conventions RFC here, I think. But it's hard to get there without some experimentation first.

what i interpret is that there's no preference in wanting either way. afaik no conventions RFC exists yet. has any experimentation been done?

IMO creating a private-but-actually-public SpecToString trait to hide away the specialization possibility does not provide much benefits over keeping ToString specializable, as long as #31844 min_specialization is still unstable.

what i interpret is that there's no preference in wanting either way. afaik no conventions RFC exists yet

While not technically being an RFC, the std-dev-guide specifies that specialization should use private traits https://std-dev-guide.rust-lang.org/code-considerations/using-unstable-lang/specialization.html

IMO creating a private-but-actually-public SpecToString trait to hide away the specialization possibility does not provide much benefits over keeping ToString specializable, as long as #31844 min_specialization is still unstable.

I agree with that, however at least the change makes it consistent with how specialization is handled in the rest of the stdlib.

IIRC the reason for hiding specializations had something to do with the specialized methods being nameable through fully qualified function calls, e.g. <SpecializedImpl as Trait>::specialized_function. The part that I don't recall is what the negative impact of that was. 😅

☔ The latest upstream changes (presumably #92598) made this pull request unmergeable. Please resolve the merge conflicts.